Typical real-time OS implementations offer various timer services that can be used for a variety of applications and services. These timers can be used to trigger events such as notifications, alerts and signals.
Some recent protocols require a very large number of timers with relatively small periods along with timer or periodic events with significantly longer periods. The context switching associated with the handling of these timers can overwhelm most OS very quickly, especially when the capabilities of the hardware platform cannot be expanded for various reasons, including but not limited to cost.
Another problem area occurs when multiple timers (periodic or not) are set to expire at the exact same time, although they belong to unrelated processes, services or applications. The state of the art approach often results in peaks of timer activity followed by relatively quiet periods for the next immediate timer tick.
An example of the existing state of the art in timer distribution is given below: When a timer is created, the timer tick period specified in microseconds or nanoseconds (as it is defined by the operating system) is converted into the corresponding number of OS ticks. A calculation is then made to insert this tick value into the proper slot at the proper level. For example, in the case where the timer tick period, that is the time between successive ticks of the timer or successive timeouts is 5000 μs (microseconds), and the OS tick period is equal to 1666 μs,timer_tick period=5000 μst=1666 μs (OS tick period)t_tick=time_value/t then t_tick=5000/1666=3 ticks                that is, the timer would have to be triggered every 3 OS ticks        
FIG. 1 shows the distribution of timers assuming that there are 3000 of these 3-OS-tick timers. When examining the number of interrupts 101 calculated over time in OS ticks 102, it can be seen that while normally the system has only 1 interrupt per tick, during a slot from the set of slots {3, 6, 9 . . . } the interrupt per tick spikes to 3001. This means that the system has large peaks of activity 103 with low points of inactivity 104. This leads to very high workloads (perhaps more than can be handled) in one OS tick for the system at peak 103 and relatively little work at point 104.
There is therefore a need to smooth out these timer events over a slightly larger period of time to achieve a more efficient use of the OS resources without affecting the overall adherence to standards, the quality of service or the overall quality of experience.